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INTRODUCTION 



System control of user applications and system functions is 
accomplished witnin the framework of the task group. A task 
group consists of a set of relatec tasks. The most simple case 
of a task is the execution of code produced by one compilation 
or assembly of a source program (after the code is linked and 
loaded) . 

A task group is both the owner of system resources and the 
context In which system control of tasking is accomplished. A 
task can t>e characterized as the execution of a sequence of 
instructions that has a starting point and an ending point, and 
performs some identifiable function. It is the unit of 
execution of the Executive, and Us execution must be requested 
through the Executive software. 

The source language from which task code is derived can be any 
of the languages supported by the Executive. Source code ^s 
compiled (or assembled) and linked to form bound units 
consisting of a root and zero or more overlays. (Refer to 
"Bound Unit Characteristics 1 ' later in this section for more 
information.) 



TASK GROUPS AND TASKS 



You car. configure a system dedicated to interactive applications 
or to a combination of interactive and absentee applications. 
This flexibility of configuration is based on the concept of the 
task group as the owner of the system resources it requires for 

execution. 

By defining more than one application .task group to run 
concurrently, you are utilizing multiprogramming. You can step 
through an application in sequence by causing tasks in the group 
to be executed one at a time, or you can multitask an 

application Dy causing tasks within the group to be executed 
concurrently. 
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Multiprogramming 



Since multiple applications can be loaded Vn memory at the same 
time, contencing for system resources, the system birlder must 
define an environment for eac* application so that the 
application knows the 1-imits of its resources. This defined 
environment is called a task group, and its domain includes one 
or more tasks, a memory pool, files, peripheral devices, and 
priority level s. 

By defining the total system environment to corsist of more than 
one task group, the system builder divides up tne resources so 
that more than one application can run concurrently. To do this 
the system bullaer dlvices the memory net occupied by the 
Executive into one or more user memory pools. Lsers assign task 
groups to memory pools at group creation time. Task code of a 
task group is Icaced into this task group's pool; the task 
obtains dynamic memory from that pool. 



Task Step Control 



By using the resources of one task group repetitively, you can 
run an application as a secuence cf job or program steps. To do 
this, you invoke the Spawn Group command to create a task group 
that uses the Commanc Processor (whose function is to .process 
system- level commands). You can enter comnancs through task 
groups whose lead task is the Menu Processor or the Command 
Processor, 

One method of sequencing application steps is to have this 
spawned group issue a Spawn Task command for eacn task to be 
executed. This conmand causes a task to be loaded, executed, 
and then deleted. Provided the Comnanc Processor is instructed 
to wait for completion of each spawned task, the tasks in the 
group can be executed in sequence. For example: 

ST 1 -EFN REP.DATA -WAIT 

[Spawn task to gatner report data and wa-t for it to 

complete) 

ST 1 -EFN PR.RPT -WAIT 

(Spawn task to print report and wait for it to complete) 
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Multitasking 

A variation of step control can be used to attain multitasking 
within one task group- Consider the situation in which the 
Conroand Processor is the lead task and reads a file containing 
Spawn Task commands- The Command Processor does not wait for 
the execution of the individual tasks; rather it continues to 
spawn tas<s until it reads an end-of-file or &Q directive. The 
spawned tasks are loaded and run concurrently in this task 
group, contending among themselves for the resources belonging 
to the group. For example: 

ST 1 -EFN REPJ3ATA 

(Spawn task to gather report data) 
ST 1 -EFN PR_RPT 

(Spawn task to print report) 

Synchron- This method can be used only if a synchronization mechanism such 

ization as a semaphore is employed to ensure that PR_RPT does not run 

until REP_DATA has finished (refer to "Semaphores'* in Section 5 

for further information). 

In a multiprocessor system it is possible that the PR_RPT 
program will be started before REP.DATA has finished gathering 
its data. In any system, each task is given a certain amount of 
time to execute, after which it must wait for some event. If 
the task exceeds this amount of time, the system schedules it to 
resume after other tasks. It is possible that REP_DATA could be 
stooped before it has finished collecting the data and that 
PR_RPT could be started. For reasons such as these, a 
synchronization mechanism is a necessity. 
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Lead Task 

The Command Processor must be the lead task of an absentee task 
group so that "t can read the EC file containing the desired 
commands- However, the Command Processor does not have to be 
the lead task of an interactive task group. An application 
consisting of one task could execute in a task group whose lead 
task is the application task. 

If the application requires step control or multitasking and you 
do not need to use commands for control, you can generate a task 
group whose lead task contains the Assembly language system 
service macrocalls whose functions are analogous to the Create 
Group, Create Task, 5pawn Group, and Spawn Task commands. 

These situations are illustrative and do not exhaust the various 
ways in which you can control program execution. 

Application Design Benefits of Task Group Use 

Designing an application around a task group provides intertask 
communi cation and Executive control of multiple unrelated task 
groups. 



Intertask Communication 

The tasks in a task group execute asynchronously under control 
of the Executive. Tasks within a group can use control 
structures supplied with each task request for intertask 
comnuni cation. 

Asynchronous tasks proviae effective software response to 
information received from real-time external sources, such as 
communications or process control systems. Usually, the task (a 
line protocol handler) that is activated to handle the interrupt 
from the external source has a higher priority and a shorter 
execution time than the task that processes the information. 
The task that responds tc the interrupt will use the Executive 
to request the execution of the processing task, supplying along 
with the reouest a control structure containing a pointer to the 
new information to be processed. The Executive responds to the 
request by activating the requested task or by queuing the 
request if ether reouests for the execution of the task are 
still pending. 
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CDmrrunicatio r 5 applications car use a Mgti priority task to 
respond to data interrupts and determine which processing task 
should handle the data. This higher priority task uses the 
system to queue requests for the processing task, thereby 
accommodating peak-load conditions in which data is received 
faster than it can be processed* 
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System Control of Task Groups 

Job/Step System control of an application based on the use of multiple 

Sequencing task groups is important for several reasons. First, these 
applications can be thought of as consisting of multiple 
unrelated "jobs" (task groups) made up of one or more "job 
steps" (tasks). The sequence of task execution can be 
controlled by the system (Command Processor) as n processes 
synchronously supplied commands instead of responding only to 
externally suoplied interrupts. The next "step" is started only 
when the previous step terminates. (You must ensure that the 
steps will be carried out in order.] 



Resource Use 



Job 
Incependence 



If any one set of tasks does not fully use the available 
processing time, the system car make more efficient use of 
resources by rotating their use on the basis of Interrupts and 
priority level assignments. 

The use of independent task groups that are subject to system 
control prevents one task group from adversely affecting 
another. ]f an error occurs in one task group, this group can 
be aborted while the others continue to execute. 
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Generating Task Groups and Tasks 



Generation 
Commands 



The system proviaes tasking facilities "egardless of the source 
code in which the application is written. Once generated, all 
tas<s are suoject to the same system controls, whether written 
in COBOL, FORTRAN, BASIC, Pascal, C, Ada, or Assembly language. 

Some languages (such as COBOL and BASIC) dc not provide for 
tasking as part of the programming language's capabilities. In 
tnese cases, the generation of tasks consisting of code written 
in those languages is done through commands. 

Although tasks written in languages such as Assembly language 
and FORTRAN can be generated at the control language level, 
these languages have a facility for generating task groups and 
tasks without recourse to commands. Assembly language programs 
use system service macrocalls; FORTRAN programs use tasking 
routines. 

From the overall system viewpoint, the actions of the control 
language in the generation of task groups and tasks are much 
more visible thar the same capabilities in Assembly language and 
will be considered next. 

As shown in Table 4-1, commands submitted oy the operator and 
commands submitted by other users share some of the task group 
generation functions and also perform unique functions. The 
control commands are divided into three g^ouos: 

1. Commands tnat perform the same function whether submitted oy 
the operator or another user. 

2. Commands that can be enterec only by the operator. 

3. Comrands contained witnin the content of an existing task 
group request. 
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Table 4-1. Task Group and Task Functions Possible 
From Interactive and Absentee Modes 



Function 


User Corrmands 


Operator Commands 


Interactive 


Absentee 


Interactive 


Absentee 


Create Group 


Yes 


No 


Yes 


Yes 


Enter Group Request 


Yes 


Yes 


Yes 


Yes 


Delete Group 


Yes 


NO 


Yes 


Yes 


Abort Group 


Yes 


No 


Yes 


Yes 


Spawn Group 


Yes 


No 


Yes 


Yes 


Bye 

Suspend Group 

Activate Group 


Yes 


Yes 


NO 

Yes 
Yes 


NO 
Yes 

Yes 


Only operator commands 
exist for these 
functions. 


APort Group Request 




Yes 


Yes 


Create Group Request Queue 
Create Task 
Delete Task 




Yes 


Yes 


Yes 
Yes 


Yes 
Yes 


Only user commands 
exist for these 
functions. 


Enter Task Request 


Yes 


Yes 




Spawn Task 


Yes 


Yes 




NOTE: The Corrrn 

absentee 


and Processor executes in 
mode. 


interactive and/or 
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Characteristics of Task Groups and Tasks 

Task" groups and individual tasks can be originated in either of 
two ways: by creation or by spawning. The choice depends on 
application design considerations as well as the intended 
functions. 

There are important differences between tasks (and task groups) 
that are generated by a create function and those originated by 
a spawn function. Created task groups and tasks are permanent; 
they remain available in memory until explicitly removed. 
Spawnec task groups and tasks are transitory; they perform a 
function and disaopear. 

Createa task groups and tasks are passive; they must be 
explicitly requested to execute in oraer to perform their 
intended function. Spawned task groups and tasks cannot be 
requested. The spawning of a task group or task is equivalent 
to a create-request-delete sequence of control language 
cormands. In a spawn operation, the task group or task is 
defined, provided with system resources and control structures, 
executes, terminates, and has its resources deallocated, all in 
one continuous process. 

"ask ;ode may cause extensive action 1n its own behalf, as when 
application task code requests a system service or the execution 
of another task while awaiting the completion of the requested 
task. Each task that requests another supplies the address of a 
control structure through which the issuing task and t.ne 
requestec task can communicate, and which tne Executive uses to 
coordinate task processing. 
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Task Group Identification 



Each task group has a unique identifier. Honeywell Bull 
supplied system task group identifiers begin with a $, as 
below: 



shown 



Task 
Group ID 


Function 


$H 
$L 
$P 
$S 


Honeywell Bull-supplied user task group 
Listener 
Deferred print 
System task group 



Group-Id The identifier for a user task group in the Create Group or 

Spawn Group command is a 2-character name that should not have 
the dollar sign (S) as its first character. The identifier (or 
group-id) can be indicated or implied in commands to designate 
what task group is to be acted upon. The operator can include 
the task group identifier when responding to operator terminal 
messages from the task group. 
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MEMORY MANAGEMENT AND PROTECTION 

The system (hardware and software) provides a memory management 
anc protection facility that performs the following functions: 

• A* locates memory to guarantee each task group (user) its own 
address space, 

• Protects multiple users from each other and the system from 
the users. 

The hardware used to provide memory management anc protection is 
called a memory management unit. The type of memory management 
unit varies according to the kino of processor. DPS 6 systems 
use either tne Basic Memory Management Unit (BMMU) or the 
Extended Memory Management Unit (EMMJ). Each of these memory 
management units is based on tne concept of segmentation. 

Segmentation 

The memory management unit maps a segmented address space onto 
physica' memory. The unit of memory "a 1 location is a segment. A 
segment is a variaoly sized area of memory that usually consists 
of a logical entity such as a procedure. The system memory 
management and protection facility treats all aadresses 
generated by the central processor as segment-relative 
addresses. It maps the segment-relative addresses through the . 
memory management unit to absolute physical addresses. 

Segment Size No segment-can t>e less than 512 bytes in *ength. Segment size 
is always a multiple of 512 bytes. 

Segmentation Wrth Basic Memory Management Unit 

Tne BMMU supports up to 31 segments, 15 of which can be up to 8K 
bytes (K=1024) in size and 15 of which can be up to I28K bytes 
in size. The segments that can be up to 8K bytes are called 
"small segments"; those that can be up 128K bytes are called 
"large segments." The 16 small segments are numbered from 0.0 
through 0.F; the 15 large segments are numbered from 1 through 
F. All small segments, and often some large segments, are 
reserved for system use; tne actual number reserved is 
established at system generation. 

The BMMU provides a total cf 2 million bytes of segmentea 
address space for each task. 
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Each segment is described by a 4-byte segment descriptor that 
contains the segment's starting physical address, its length -(in 
units of 512 bytes), and its access rights for each ring (refer 
to "Segment Ring Protection" below). 

Although you can assign any of the large segments to a bound 
unit when it is linked, the availability cf a segment depends on 
the system configuration. Therefore, most applications simply 
let the system assign segment numbers. The identity of the 
segments available to you should be obtained from the system 
administrator. 

Segmentation With Extended Memory Management Unit 

The EMMU supports up to 256 segments, each of which can be up to 
128K bytes in size. The segments are numbered from 00 through 
FF. Segments 00 through 7F are reserved for system use; 
segments 80 through FF are available for user tasks. 

The EMMU provides a total of 32 million bytes of segmented 
address soace for each task. 

Each segment 1s described by a 2-byte segment descriptor that 
contains the segment's starting physical address, its length (in 
units of 512 bytes), and its access rights for each ring. 

Segment Ring Protection 

Access to memory segments is controlled through the memory 
management unit. The memory management unit assigns each 
executing task to a ring of privilege. (Rings may be thought of 
as concentric circles, like a target. The innermost circle, 
ring 0, has the most privilege.) During the linking of a bound 
unit, ycu can assign access attributes to each bound unit to 
Indicate whether a task executiog in a particular ring of 
privilege can read, write, and/or execute 1n the code or data 
segment of the bound unit. However, it is recommended that you 
use the system defaults. 

Task System tasks execute in ring (privileged state). User tasks 

Execution can execute in rings 2 and 3. Ring is most privileged, and 

ring 3 is least privileged. The ring in which a user task 
executes is defined by the type of memory pool to which the task 
has been assigned (refer to "Ring Access Rights" later in this 
section) . 

Access Every attempted access to a segment is checked for legitimacy. 

Checking The system compares the ring number of the executing task with 

the access attributes of the segment to be accessed. An access 
violation trap occurs if a user application attempts to access 
one cf its segments without having the proper access rights. 
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MEMORY POOLS 



At system startup the Configuration Load Manager (CLM) reads a 
file of directives, sets up memory pools from the supplied 
specifications, and indicates to the Loader wnat system and 
use** -written software is to be resident for the life of the 
system. On the DPS 6/22, the Autoconf igurator creates the 
file. On other systems, the system builder can use the line 
editor to create the file. 

After the system has been in operation for a while, experience 
may show the desirability of reconfiguring the pool sizes so 
that they meet user requirements more precisely. The system 
builder can hand-tailor trie MEMPOOl and SWAPPOOL directives in 
the CLM file using the line editor. Refer to the System 
Building and Administration manual for information on the CLM 
directives. 

The system supports the following types of memory pools: 

• System pool - Contains the system task group and all 
globally shared elements. There is only one system pool per 

system. 

• Swap pool - Provides an environment in which segments can be 

swapped out to disk to make room for competing users, and in 
which the memory requirements of individual users do not 
have to be predetermined. Systems with EMMUs should have 
all of user menory as one swap pool. Systems with BMMUs 
should have all of user memory as multiple swap pools. 

• Independent pool - Provides an environment suitaole for 
applications with well-defineo memory requirements, all of 
whose tasks must must be in memory at the same time. There 
can Be multiple independent pools In the system. 

Swap and independent pools allow app-ications running on systems 
with a BMMU to access more tnan 2 million bytes of physical 
memo ry . 

If multiple swap or independent poc'is are configured, Listener 
can optionally ensure an even distribution of task groups among 
memory pools by assigning each new user to the memory pool with 
the fewest task groups. 



Sharing Memory Pools 



Swap and independent pools will be shared if users assign more 
tnan one task group to the same pool. As the tasks execute, 
they contend for the same memory space. Tasks running in an 
i~depencefit poo 1 , should be designed sc that tney can be 
suspended or take some alternative action when no additional 
memory is avai lable. 
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Memory Pool Attributes 



Protection 



Containment 



Privilege 



Memory pools can have one or more of the following attributes 
protection, containment, privilege, serial-usage, and ring 
access rights. 



When a memory pool has the protection attribute, it cannot be 
written into by a task running in another pool. The Executive 
uses the memory management unit to prevent all write Intrusions 
by foreign tasks. A task attempting to write into a protected 
pool receives an error notification from the Executive. 

Protection applies to memory pools and not to task groups. 
Groups sharing a a memory pool are protected from each other 
only in the swap pool. Tasks within a group are not protected 
from each other. 

All pools are automatically generated as protected; this 
attribute cannot be changed. 



When a memory pool has the containment attribute, tasks running 
in the pool cannot write outside the pool area. The Executive 
uses the memory management unit to prevent all tasks from 
writing outside the pool. A task attempting to write outside of 
a contained pool receives an error notification frorr the 
Executive. 

The system pool cannot be contained. Swap and independent pools 
are automatically generated as contained; this attribute cannot 
be changed. 



When a memory pool has the privilege attribute, any task running 
in that pool can execute privileged instructions. The following 
Assembly language instructions are privileged: 



A5D 10 LEV 
CNFG 10H RTCF 
HLT IOLD RTCN 



WDTF 
WDTN 



If the pool dees not have the privilege attribute, any task 
attempting to execute one of the above instructions will trap. 

The system pool is always privileged: this attribute cannot be 
changed. Swap and indepenoent pools are unprivileged; this 
attribute can be changed in the CLM MEMPOOL directive. 
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Serial Usage 



When a memory pool has the serial -usage attribute, it can be 
usee by only one task group at a time. 

The system and swap pools are generated without the serial-usage 

attribute; this specification cannot be changed. Independent 
pools can be specifieo in the CLM MEMPOOL directive as having 
the serial-usage attribute. 



Ring Access Rights 



Each type of memory pool is automatically assigned a ring access 
Obsignation. There are four rings, numbered through 3. Rings 
and 1 are privileged rings; rings 2 and 3 are unprivileged* 
Tasks acquire the ring attribute of the pool to wnich their task 
group is assigned. The pools and their associated rings are: 



Pool 


Ring 


System 

Swap 

Independent 



3 

1 or 2 



Independent pools have ring 1 access if they are privileged and 
ring 2 access if they are not privileged. 

Accessing Ring access is used with segment ring protection to determine 

Memory the ability of a task to access memory (refer to "Segment Ring 

P-otection" earlier in this section). A task whose ring access 
is 2 can only access memory protected at ring 3. A task wnose 
ring access is 2 can only access memory protected at rings 2 and 
3. A task whose ring access is 1 can access memory protected at 
rings i, 2, anc 3. A task whose ring access is can access 
memory protected at rings 0, 1, 2, and 3, 



The following paragraphs describt 
greater detail. 



each type of memory pool in 



System Pool 



Jser Groups 



The system pool contains the system task group (55), certain 
file control structures, and system elements that are to be 
shared. Its maximum size is 4 million bytes. The system pool 
is protectee, privileged, and not contained. Tasks running in 
this pool have ring access. 

Jser task groups cannot be created in the system pool. User 
tasks cannot execute in the system pool with ring access. 
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System The system tas< group cannot be aborted or suspended. Since it 

Group never terminates, it cannot be requested. The system group 

always has read and write access to all of memory. It handles 
all system dialog (including operator commands) through the 
CLM-designateo operator terminal. 

System The file control structures in the system pool are the File 

Elements Description Blocks (FDBs) and the buffers for shareable files. 

Other system elements 1n this pool include: 

• Current function invoked by an operator command. 

• Extended Trap Save Areas (TSAs) needed during processing. 

• Control blocks for all tasks (TCBs) and task groups (GCBs). 

• Globally shareable bound units* 

• File System directory and file definition blocks. 

• Public buffer pools. 

• Memory control blocks for swap pool segments. 

Swap Pools 

A swap pool is a privileged, protected, and contained pool in 
which segments can be swapped out to disk in order to make 
physical memory available to competing users. Swap pool memory 
rranagement can move segments to physical memory in order to 

eliminate fragmentation and consolidate available memory space. 

Swap pools support both interactive and absentee processing. 

Size The si2e of a swap pool, plus the size of the Executive and its 

structures, cannot exceed 2 million bytes in a system having a 
BMMU and IS million bytes in a system having an EMMU. On 
systems with a BMMU, the system builder can configure multiple 
swap poo" s. On systems with an EMMU, all of user memory should 
be one swap pool . 

Virtual A swap pool is a separate virtual view of the system. That is, 

View each task in a swap pool can view that portion of the pool 

relating to itself and can view all of the global system space. 

Tasks running in the swap pool have ring 3 access. 
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Swapped Out The system acquires soace for a given segment from whatever 
portion of free swap pool memory is available. If not enough 
space is available for the needed segment, the system attempts 
to obtain memory by swapping out lower priority tasks in the 
same pool that are waiting on an event. If this action aoes not 
produce enough memory, the. requesting task is swapped out until 
sufficient space becomes available. A task is swapped cut under 
one of the following conditions: 

• If it *s waiting on an event that is of potentially long 
duration and swap pool memory 15 required by a comoeting 
task. 



Swapped In 



Task In 
Memory 



Protection 



Segment 
Assignments 



• If memory is required to roll in a higher priority task. 

• If the task has been suspended by the operator. 

A task is" swappec back in when the swap pool memory is 
available. The task may be swapped in immediately, it may be 
swapped in after tasks waiting on events of long duration are 
swapped out, or it may be swapped in after lower priority tas 
are swapped out. A task is swappec back in when any event on 



A task is swappec back in when any event on 
which it was waiting nas completed or when it is reactivated by 
an operator. 

The entire context of a task in the task group must be in memory 
for the task to execute. Other tasks in the task group need net 
be in memory. However, thrashing may occur if too many users 
are assigned to too small a swap pool. 

A task in a swap pool can overwrite shared data designated for 
writing. A task cannot overwrite another task, another task's 
data, or shareable read-only data. Further, tasks in a swap 
pool can only read (not write) system structures. 

Tasks running in a swap pool have logical elements (for example, 
bounj un-ts) equated w-f segments. The Executive a'icrs the 
logical elements on segment boundaries. This configuration is 
represented in Figure 4-1. 



SEGMENTS 

... 1.0 2.0 3.0 


4.0 5.0 


6,0 


SYSTEM GRCLP DATA 
POOL GAP SPACE 


GROUP wORK 
SPACE 


BOUND 



Figure 4-1. Sample Swap Pool Group Segment Assignments 
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Each task group m the swap pool has group global space that 
cannot be accessed by any other group. Each task in a swap pool 
group can have task private space that cannot be accessed by any 
other task. For further information refer to "Swap Pool Task 
Address Space" later in this section. 

Independent Pools 

An independent pool is protected and contained; it can be 
privileged or not and serial-usage or rot. Tasks running In an 
independent pool have ring 2 access if the pool is unprivileged 
and ring 1 access if it is privileged- 
Independent pools support both interactive and absentee 
processing. 

Size The size of an independent pool, plus the size of the Executive 

and its structures, cannot exceed 2 million bytes in a system 
having a BMW and 16 million bytes in a system having an EMMU. 
On larger systems, multiple independent pools can be configured. 

It is important that the memory requirements of the group(s) 
using an independent pool be estimated carefully because the 
entire context of a task group must be in memory for a task in 
the group to execute. It is possible that task group memory 
requirements may exceed trie size of the. memory pool because of 
memory fragmentation. 

Protection Note that even with protection and containment, a task in an 

independent memory pool can accidentally overwrite code or data 
belonging to its own or another group 1n the pool. 

Virtual View Each independent pool is a separate virtual view of the system. 
That is, each task in an independent pool can view that portion 
of the pool relating to itself and can view all of the global 
system space. Thus, a task in an independent pool can reference 
a memory location in that pool and In system global space. 

Use Independent pools are designed for applications that you may not 

want to execute in a swap pool. 
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Segment The system aligns user memory pools on segment boundaries 

Assignments (multiples of 512 bytes). This configuration is shown in 
Figure 4-?. 



SEGMENTS 
. . . 1.0 


2.0 


3.0 4.3 


5.0 


SYSTEM 
POOL 


GAP 


INDEPENDENT 

POOL GAP 


INDEPENDENT 
POOL 



Figure 4.-2. Sample Independent Pool Group Segment Assignments 



Selecting Memory Pool Types 

The different types of menory pools provide you with the means 
to respond to the unique demands of multiple application 
programs. Through the use of memory pools, you Can exercise 
control over memory usage and, at the same time, provide 
individual task groups with specialized protection. 

The degree to which the system can efficiently and effectively 
nandle tne concurrent execution of multiple task groups depends 
on the number and type o* memory pec's available for use. The 
following points should be kept in nvnd: 

• All systems must have a system pool. 

• In systems with a BMMU, all user memory should be devoted to 
multiple swap pools. 

• In systems with an EMMU, all user memory should be one large 
swap pool . 

• One or more independent pools can be selected for 
applications that you do not want to rur in a swap pool. 

Default If you do not configure any memory pools, you will be provided 

Memory Pool with one swap pool whose si2e is all of memory, less the amount 
of memory occupied by the system pool. 
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Memory Pool Layout 



To obtain efficient use of memory and of the memory management 
unit, the CLM sorts the memory pools specified in a 
configuration as follows: 

1- The system pool is configured in the first available memory 
after the system data structures. The system pool cannot 
exceed A million bytes. 

2. If swap pools are configured* they follow the system pool* 

3. Independent pools are configured after an swap pools. 



Fixed System Area 



After the configuration process is complete, the following 
software components and data structures are located in the fixed 
system area of merrory: 

• Basic Executive plus resident overlays 

• User-written or vendor-supplied extensions to the Executive 

• Device drivers 

• Intermediate request blocks needed for task groups 

• Trap save areas 

• Overlay area(s) for system software 

• File control structures. 

The fixed system area is static. Unlike the ether memory areas 
whose contents can vary dynamically, its structure remains the 
same for the life of the system. Almost all code loaded Into 
this area is reentrant so that a single copy of the code is 
available to multiple users, thus minimizing memory 
requirements. 



CZC3-02 4-21 



Execution Environment 



BOUND UNIT CHARACTERISTICS 

Task coae is derived from programs written in a source language 
and compiled or assembled to form object units (also called 
compilation units). One or more object units are linked to form 
a bouna unit that is placed on a file. The bound unit 1s an 
executable program that can be loaded into memory. A task 
represents the execution of a bound unit. 

General Bound Unit Characteristics 

Bound units have the following general characteristics: 

• Each bound unit consists of a* root segment and any related 
overlays. 

• A load element is composed of one or more object units. 

• The initial load element is called the root; 1t must be 
resident when the bound unit is being executed. 

• A load element that replaces another load element when 
loaded into memory is called an overlay. 

Linker You can direct the Linker to perform the following actions on 

Actions bound units: 

• Map the code and data into the same load element or into 
separate elements. If the bound unit is to be reentrant, 
the code and data must be in separate load elements. 

• Specify ring access rights. If the bound unit is to be 
reentrant, the default access attributes are ring 3 read and 
execute access for both code and data, ring write access 
for the code segment, and ring 3 write access for the data 
segment. 

• Associate a specific segment numbe" or numbers with a bound 
unit. Normally, the Linker assigns default segment 
numbers. If you assign segment numbers at link time, you 
must be careful to avoid segment conflicts in the 
configuration and application environment in wnich the bound 
unit is to run so as to avoid inefficient loading. 

Address Vour physical address space is riot necessarily contiguous. 

Soace Memory requirements are satisfied on a segment basis rather than 

on a user basis. 

Note that for systems with a BMMU, you have a maximum of li 
large segments avallafc'e when constructing a task's address 
space. Frequently, fewer large segments will be available, 
cepending on the system configuration. 
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Shareable Bound Units 



The use of shareable bound units is a way cf minimizing 
application task group memory requirements while making 
reentrant code available to multiple tasks. Unlike permanently 
resident bound units that are loaded during system 
configuration, shareable bound units are transient in memory and 
are loaded during processing. A usage counter is incremented 
each time a request is made for the bound unit, and decremented 
each time a request is completed. The unit remains in memory as 
long as a task is using the code. As soon as the usage counter 
is decremented to zero, the space occupied by the bound unit is 
returned to available status. 



Shareable Bound Units In Swap Pools 



If a bound unit is shareable only w'thin a swap pool, its root 
segment descriptor is placed in a portion of memory where it is 
accessible to all tasks in that pool. The bound unit should 
have no fixed overlays; floatable overlays can be shared if an 
OAT is used. (See "Bound Unit Overlays" later in this 
section.) To be recognized as shareable by the Loader, and to 
be loaded into a user memory area, the bound unit must have been 
linked using the SHARE directive. 

Additionally, task private segments are shared if the task 
forks. (A task forks if it issues a Create Task or Spawn Task 
corrmand with an entry point address rather than a pathname 
definition.) Forked tasks share the same segments; they have 
the same access to and copy of the forked segments until one 
task modifies its address space. (Address space defines a 
task's boundaries in a swap pool. Refer to "Swap Pool Task 
Address Space" later in this section.) 



Shareable Bound Units In Independent Pools 



In an independent pool, bound units can be shareable by tasks 
within a task group or can be shareable by all task groups. 
Shareability is established when the bound unit is linked. To 
be shareable by tasks and task groups within a pool, the bound 
unit must be linked with the SHARE directive. Bound units 
linked with the SHARE directive are loaded into the requesting 
task group's memory pool. 
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Globally Shareable Bound Units 

To be shareable oy task groups in other oools (globally 
shareable), the Dound unit must be linked with the GSHARE 
directive. Bound units linked with the GSHARE directive are 
loaded into the system pool. Since system pool memory is a 
critical resource, the use of globally shareable bound units 
requires careful planning and control- If all of user memory is 
one large swap pool, the SHARE directive has the same effect as 
the GSHARE directive, and does not clutter up the system pool. 

Operator comnands can be used to load and unload globally 
shareable bound units. 

Shareable Bound Units And Executive Extensions 

Shareable bound units and the Executive extensions that are 
loaded through LDBU directives when the system is configured 
differ 1n one major respect. Executive extensions can be 
accessed symbolically by any task, but a shareable bound unit 
must be accessed as a bound unit. 

When an Executive extension is loaded during system 
configuration and is made permanently resident by an LDBU 
airective, its symDOls are included in the system symbol table- 
Since a shareable bound unit is transient and is loaded after 
the system has been configured, no entry is made for it in the 
system symbol table. For this reason, it must be accessed as a 
bound unit. Table 4-2 compares permanently resident Executive 
extensions and transient shareable bound units. 
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Table 4-2. Comparison cf Executive Extensions and 
Shareable Bound Units 



Characteristics 


Executive 
Extension 


Shareable Bound 
Units 


Multiple users 


ves 


Yes 


Permanently resident 
(fixed system area) 


Yes 


NO 


Temporarily resident 
(system or user pool) 


No 


Yes 


Symbols in system table 


Yes 


No 


Accessed symbol ically 


Yes 


NO 


Have overlays 


No 


Yes ■ 
(See Note 2) 


Called by bound unit name 


No 


Yes 


NOTES: 1. If the extension is an Assembly language bound 
unit, it may have within it sections of code or 
control structures control 'ed by semaphores that 
would be accessible to other Assembly language 
tasks (refer to "Semaphores 11 in Section 5 for 
further information). 


2. Overlays are not shareable unless Overlay Area 
Tables (OATs) are used (refer to "Bound Unit 
Overlays" below). 


3. The Executive does not "remember" extensions by 
their names. A request for an extension by name 
results in another copy being brought into 

memory. 



Bound Unit Search Rules 



The Loader uses search rules to locate a bound unit to be 
loaded. The Loader starts the search in response to a command 
containing an argument naming the bourd unit to be loaded. 
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The rules that regulate the search process define three 
directory pathnames and the sequence in which they are used 
curing a search. The pathname seauence is as follows: 

i. User task group working directory. 

2. System directory -LIB1 argument of the Change System 
Directory command. 

3. System directory -LIB2 argument of the Change System 
Directory command. 

The Change System Directory command can be used to change 
pathnames associated with system directory arguments -LIB1 and 
-LIB2. The pathname of a user's working directory is 
established through a Change Working Directory command or 
through the -WD argument of the Enter Group Request or Spawn 
Group command. For log'n users, the -WD argument of the Spawn 
Group command issued by tne Listener is taken from the -HD 
argument in the Login command line. 



Bound Unit Overlays 



In smaller systems, you may need to minimize the amount cf 
memory required to execute a bound unit containing application 
code. Vou can accomplish this by directing the Linker to create 
the bound unit as a series of overlays (separately loadable 
pieces) so that the entire bound unit does not have to be 
resident at one time. Each bound unit consists of a root and, 
optionally, one or more related overlays. The system loads the 
bound unit root automatically when the bound unit is invoked. 
Overlay loading is controlled by the application itself. The 
maximum number of overlays is 65,536. The use of overlays 
requires careful planning so that required code is not lost or 
repetitively loaded. 

Two types of overlays are available for your use: nonfloatable 
and floatable. In addition, you can use overlay areas to 
control the placement of floatable overlays* 



Nonfloatable and Floatable Overlays 



Overlays can be loaded at a f ixed displacement from the base of 
the root (nonfloatable overlay) or into a block of memory 
allocated explicitly oy you or implicitly by the system 
(flcatable overlay) . 
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Nonfloatable A nonflcataole overlay 1s loaded into the sane memory location 
relative to the root each time 1t is requested. Object units 
whose code is to be loaded as nonfloatable overlays must be 
defined as fixed overlays by the Linker OVLY directive. When 
the root of a bound unit having fixed overlays is loaded, the 
Loader allocates a container (segment or memory block) large 
enough to hold the root and all of its fixed overlays. 

Assembly language programs can use system service macrocalls to 
load and execute nonfloatable overlays. COBOL programs can use 
CALL/CANCEL statements to control nonfloatable overlays. 
FORTRANA and Pascal provide overlay handlers as part of the 
run-time libraries. BASIC programs must link a user-written 
Assembly language overlay manager with the application program, 
since the BASIC language does not supply this functionality. 

Floatable A floatable overlay is linked without having a fixed relative 

location to the base of the root. It can be loaded into any 

available memory location. Floatable overlays must meet the 
following criteria: 

1. The overlay must not contain external definitions referenced 
by the root or another overlay. 

2. The overlay must not make displacement references to the 
root or any other overlay. 

3. The overlay must not contain external displacement 
references that are not resolved by the Linker. 

The application program can use one or more areas of available 
memory for the placement of floatable overlays. The program can 
deal with memory management in one of the following ways; 

1. Allow the system to place the overlay in an available memory 
block allocated from the user's independent memory pool or, 
if loaded in a swap pool, from group work space. (Group 
work space ^s a segment common to all tasks in a group. 
Refer to "Swap Pool Task Address Space" later in tMs 
section.) 

2. Create a set of overlay areas using system service 
macrocalls, and allow the system to manage the areas and 
locate the requested overlays. In an independent memory 
pool, the overlay areas are created from a memory block in 
the pool. In a swap pool, the segment(s) allocated for the 
root are expanded to contain the created overlay area. 
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3. Perform Its own memory management by linking a user-written 
Assembly language overlay manager with the root of the bound 
unit. In ar independent memory pool, you may choose to have 
the overlay occupy part or all of a memory block. In a swap 
poo", you may choose to nave the overlay occupy part or all 
of a segment. 

Linking Floatable and nonfloatable overlays are defined through the 

Lin<er. When using the Linker, forward references can be made 
tc symbols defined in object units to be linked later (the rules 
for floatable overlays must be observed). Backward references 
can be made tn symbols previously defined, provided the defined 
symbols were not purged from the Linker symbol table by a Linker 
BASE or PURGE directive. Since the specification of the BASE 
directive removes from the Linker symDol table all previously 
defined and unprotected symbols that are at locations ecjual to 
or greater than the location designated in the BASE directive, 
you must take one of the following actions: 

• Define all symbols that are to be preserved in a part of the 
root that is not overlaid. 

• Protect the symbols to be preserved by using the Linker 
PROTECT directive. 

A floatable overlay can refer to fixed addresses in the root, in 
a nonfloatable overlay, or in itself, but cannot refer to 
addresses in another floatable overlay. 

When a root or overlay of a bound unit is loaded, the Loader 
examines the attribute tables associated with the bound unit if 
an alternate entry point is specified. The Loader tries to 
resolve any references to symbols that remain unresolved by 
searching the system symbol table (that is, the resident bound 
unit attribute table). The Loader cannot resolve any references 
to symbols that do not exist in the symbol table. (Linker 
symbol tables do not exist at load time.) 

Figure 4-3 shows the relative location in memory of memory pool 
AA. Figure 4-4 is the layout of overlays in memory pool AA. 
When the root is loaded, the largest contiguous amount of memory 
necessary to accommodate the root and all nonfloatable overlays 
is allocated. Except for space for any floatable overlays, no 
other memory requests need be made. In Figure 4-4, this memory 
area begins at the base of tne root and continues to the end of 
object unit OBJD. The root consists of object units 0BJ1 and 
0BJ2. When loaded, QBJ5 of overlay ABLE will replace the 
previously loaced 0BJ2 code of the root. Similarly, the overlay 
locations were specified so that OBJC of overlay ZEBRA will 
reolace oart of OBJB. 
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Figure 4-3. Relative Location in Memory of Memory Pool AA 



RSMJTfe 
Of ROOT 



ADDITIONAL 

TAS< group 
IhfQIVATlOh 



TASK i = GLF 
STRUCTURES 



OVERLAY 
ABLE 



ADDITIONAL 
T*S< GROU» 

INKIKVA1ION 



TASK GROUT 

CONTROL 

STHlCIURES 



OVEHlav 
ZEBRA 



ADDITIONAL 
TASK GROUP 
Ifi^OHMAr.QN 



08'6.J 



TASK GftOL B 

COMTSOL 
•TTflifOTUPf^ 



OVERLAY! 
FLOAT 



Figure 4-4. Overlays in Memory Pool AA 
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Overlay Areas 



Only floatable overlays can be associated with overlay areas. 
Overlay areas are a mechanism that allows you to control the 
placement of floatable overlays without being required to write 
your own overlay manager. 

Overlay areas are fixed sire areas of memory whose use is 
controlled through an Overlay Area Table (OAT). If the bound 
unit is shareable, the overlays can be shared with other tasks 
in the task group cr with tasks in other task groups. Overlays 
can also be shared if the bound unit is replicated through the 
-SHARE argument of the Create Task command. 

You create an OAT through the Create Overlay Area Table system 
service mac recall. >ou reserve an overlay area and execute the 
overlay through an Overlay Reserve and Execute macrocall. You 
exit from the overlay througn an Overlay Release macrocall. 

As an example of overlay area use. assume that you desire to 
share both the root and the overlays of a shareable bound unit 
whose structure is shown 1n Figure 4-5. 








OVERLAY 
6 




QVEHLAV 



86-027 



Figure 4-5. Sample Bound Unit Structure for Overlay Area Use 



Assume further that tasks I, 2, and 3 (of the same or another 
zask Group) are executing the shareable bound unit and that 
task 1 has encountered a create OAT function while executing the 
root. 



4-30 



C203-02 



Execution bnvircnment 



When the create OAT function is encountered, an overlay area 
(controlled by the OAT) is created for the task group- In this 
example, the overlay area has three entries, each entry being 
512 bytes long. There is no direct relationship oetween the 
number of overlays to be shareo and trie number o e entries '.n the 
overlay area. The entries in an overlay area are of equal 
size. Voj must create overlay a^eas large enough to contain the 
largest overlay (overlay D in this example). The overlay area 
rese r vec is depicted below. 



ENTRY 1 



ENTRY 2 



ENTRY 3 



512 
BVTES 


512 

BYTES 


512 

BYTES 



When task 2 (or task 3) executes the same create OAT request 
{that is, when it executes the root), the task is given the 
address of the OAT already existing in memory. 

Assume that task 1 issues an Overlay Reserve macrocall to 
reserve an overlay area defined Dy the OAT and to load overlay A 
in that area. The code and/or data composing overlay A will be 
loaded in the first free overlay area, and task 1 will be given 
access to this area- At this instant the status of the overlay 
area is as follows; 



ENTRY 1 



ENTRY 2 



ENTRY 3 



OVERLAY A 

USAGE = 1 



USAGE = 



USAGE = 



TASK 1 



When tasks 2 and 3 now perform the request for overlay A, they 
will be given access to the existing copy of the overlay. At 
this instant, the status of the overlay area is as follows: 



ENTRY 1 



ENTRY 2 



ENTRY 3 



OVERLAY A 
USAGE = 3 


— 

USAGE = 


USAGE ■ C 



TASKS 1,2,3 



CZ03-02 



4-31 



Execution Environment 



Task 2 now reouests overlay 0, Sirce a task cannot have more 
than one overlay in an overlay a r ea at any time, tas* 2 must 
explicitly release overlay A oefore requesting the loading cf 
overlay D. "he resu't of "eleas ; nc overlay A and requesting 
overlay D is as fol lows: 



ENTRY 1 



ENTR* 2 



ENTRV 3 



OVERLAY A 
USAGE = 2 


OVERLAY D 
USAGE = 1 


JSAGE = 



TASKS 1,3 



TASK I 



A request by task 3 for overlay C will result in the following 
Situation: 



ENTSY 1 



ENTRY 2 



ENTRY 3 



OVERLAY A 
USAGE = 1 



OVERLAY D 
JSAGE = I 



OVERLAY C 
JSAGE = 1 



TASK 1 



TASK 2 



"ASK 2 



If there were another task in the group (for example, task 4), 
and the task were to request overlay B, it would have to wait 
until one cf the overlay areas was freed (by an Overlay Release 
rracrocan). If task 4 requested overlay A, C, or D, the task 
woulc be given access to the loaded copy of the overlay- 
Note that at any given instant several OATs, controlling several 
different over'ay areas, may exist. Even if a task is sharing 
overlays in different overlay areas, it cannot reference more 
than one overlay area at any given tine, The task must release 
an overlay in an OAT prior tc requesting an area for another. 

You use an Overlay Area Release macrocall tc exit frcm an 
overlay. When this call is executed, the count o*" the nurnDer of 
users of the overlay is decremented in tne defining OAT. When 
the count droos to zero, the overlay area is marked as available 
and can be reused by an Overlay Reserve and Execute function. 
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Bound Unit Allocation 

Initial Each task is associated with at least one bound unit. The 

Bound Unit initial bound unit with which a task is associated is specified 
at the time the task is created or spawned. At this time, the 
segment is created/allocated in memory, and the root is loaded 
in this segment. 

If the bound unit was Designated as shareable at link time and 
is currently residing ir memory, no loading takes place. The 
requesting task shares the bound unit already in memory, and the 
bound unit user count is increased by one. If the bound unit is 
not in memory, it is loaded. 

Attach Execution of a 'task begins with the specified bound unit. 

Bound Unit During the execution of this bound unit, the Assembly language 
user can employ system service macrocalls to load or attach 
another bound unit. Loading or attaching a bound unit causes 
the allocation and >oading of the segment containing the root of 
the requested bcund unit. (The difference between loading and 
attaching is that loading returns the entry point of the root 
segment to the issuing task, while attaching starts the 
execution of the bound unit root segment at the entry point.} 
Up to eight bound unit units can be attached. In BMMU systems, 
the availability of segment descriptors may limit you to fewer 
than eight attached bound units. 

Create During its execution, a task can issue a system service 

Segment macrocall to request the creation of a segment to be associated 

with the task's initial bound unit or any other of its 
attached/loaded bound units. The macrccall can either specify a 
segment number or allow the systerr to select the number 'n 
accordance with the specified size. 

Memory Allocation 

The allocation of memory for a bound unit depends on whether the 
bound unit is nonshareable or shareable. 

For a nonshareable bound uti.1t, each logical segment is uniouely 
mapped tc a physical segment in memory. Unless the task is 
forked or the segment is in an OAT, two or more tasks wishing to 
concurrently use a nonshareable bound unit each receive a copy 
cf the bounc unit. 
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If mere than one task ^s executing a pool-snareaole bouna unit, 
only one copy of the segment containing the "oot is allocated in 
the pool. All tasks use this single copy. Overlays of tne 
bound unit can be sharec if an OAT is used. If the bound unit 
was separated into a coce element and a data element, only the 
code element is shared. Except for forked tasks, each user has 
a separate copy of the data element. 

Segment The Memory Manager assigns a segment number (or numbers) based 

Numbers on the segment descriptors available to the task that initially 

loads the bound unit. Concurrent users must access the bou.nc 
unit under the same segment numbers. If the segment utilization 
of the second and suoseguent tasks that attempt to load the 
shareable bound unit confl lets with its segment numoer or 
assignment, an error 1s returned when the tasks attempt to load 
the bound unit. In this case, the tasks are not given 
addressability to the shareable bound unit. 

Memory Deallocation 

Assemb'y language users can explicitly deallocate a user-createa 
segment by issuing a Delete Segment macrocall.. Users can 
deallocate bound units by issuing a Detach Bound Unit macrocall 
for any but the initially assigned bound unit. A segment* can be 
implicitly deallocated from physical memory as the result of the 
task being deleted or swapped out. It is -eallocatec when the 
task is swapped back in. 

Overlay areas and defining DATs are deallocated when the last 
usage of a shareable bound unit has terminated. 
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SWAP POOL TASK ADDRESS SPACE 



Task address space defines a task's boundaries in the swap pool; 
that is, its visibility within the collection of tasks executing 
In the pool. T he following elements constitute a task's address 

space: 





• Bound unit 




• User stack area 




• Dynamically created segments 




• Group work space 




• Group system space 




• System global space. 


Bound Unit 





During its execution life, a task executes one or more bound 
units. The initial bound unit to be executed is the one 
specified when the task is created or spawned. In Assembly 
language programs, other bound units (if any) can be attached or 
loaded through the Bound Unit Attach or Bound Unit Load 
rnacrocalls. 



User Stack Area 



Tne user stack area is available to users as a work area through 
the hardware stack instructions. 



Dynamically Created Segments 



During execution, a task can extend its address space t>y 
creating segments* Assembly language programs use tne Create 
Segment macrocall for this purpose. These dynamically created 

segnents becorre part of the issuing task's address space. 
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Group Work Space 



The group woric space is common to all tasks in a given task 
group. Assembly language programs can obtain slocks cf memory 
from the group work space when they issue Get Memory 
nacrccalls. All tasks in the task group have read, write, and 
execute access to the grouo work space. 

The group work space can occupy uo to two 128K-byte segments. 
The group work space grows dynamically, as recuests for memory 
are issued. In both 3MMU and EMMU systems, the maximum size is 
256< bytes. However, this maximum is recuced to 128K bytes if 
the adjacent segment descriptor has been allocated. 



Group System Space 



One group system space is provided for each task group. The 
system control structures used to support a task group and its 
member tasks (for example, file control blocks, bound unit 
descriptors for nonshareable bound units, logical file tables, 
and logical resource tables) are allocated from the group system 
space. 

The group system space can occupy up to two 128K-oyte segments. 
The group system space grows dynamically, as requests for memory 
are issued. In bcth BMMU and EMMU systems, the maximum size is 
256K bytes. However, this maximum is reduced to 128K bytes if 
the adjacent segment descriptor has been allocated. 

System Global Space 

System global space consists of the fixed system area 
(permanently configured memory) and the system memory pool. A 
task's address space includes the segments required for system 
global space. System code and data are distributed in the task 
address space. 

System Representation of Task Address Space 

Figures 4-6 and 4-7 are examples of the mechanism used by the 
system to "epresent a task's address space. Figure 4-6 is an 
example of a system having a BMMU; Figure 4-7 is an example of a 
system having an EMMU. 
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Task Address Space In System With Basic Memory Management Unit 

The following points should be noted when using Figure 4-6. 

1. The layout of memory is logical, not physical, 

2. The layout applies orly to this example; it is possible to 
generate systems whose layout is different from that shown 
in Figure 4-6. 

3. The segments available to you for your bound units are 6 
through F. If the group system space requirements are less 
than or equal to 128K-bytes, segment 3 can be used. If the 
group work space requirement is less than or equal to 128K 
bytes, segment 5 may be used. 

4. One copy of segments 0.0 through 1 exists in the system in 
this example* These segments contain the system global 
space. All tasks 1n the system can access these segments. 

5. Segments 6 through F are unique to the task unless they are 
being shared. If one of these segments is being shared, 
each task sharing the segment accesses the same copy of the 
segment. When a segment number is assignee by the Memory 
Manager, the lowest available segment (or segments for 
objects of size greater than 128K bytes) beginning with the 
Group Work Space (GWS) segment plus 2 (segment 6 in this 
example) will be used. If all segments from GWS+2 through 
large segment F have been used, the segments GtfS+1 
(segment 5 in this example) and GSS+1 (segment 3 in this 
example) are allocated in that order, if available. 

6. Only one copy of the group work space segment (segment 4 in 
this example) exists per task group. All tasks in the task 
g r oup have unlimited access to this segment;. Only one copy 
cf the segment that contains group system space (segment 2 
in this example) exists per task group. All tasks in the 
task group have read and execute access to this segment. 
Both the group work space and the group system space 
segments are dynamically expanded as demands a^e made on 
-hem. Each space car grow to a maximum of 256K bytes if the 
adjacent ascending segment descriptor (segment 3 for the 
group system space and segmert 5 for the group work space in 
this example) has not previously been allocated to contain a 
task private segment. 
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Figure 4-5. Task Address Space in EMMU System 
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Task Address Space In System With Extended Memory Management Unit 

The following points should be noted when using Figure 4-7. 
L. The layout of memory is logical, not physical. 

2. The layout applies only to this examole; it is possible to 
generate systems wnose layout is different from that shown 
in Figure 4-7. 

3. The segments available to you for your bound units are 80 
through FF. 

4. One copy of segments 00 through 7F exists in the system in 
this example. These segments contain the system global 
soace. All tasks .in the system can access these segments. 

5. Segments 80 through FF are unique to the task unless they 
are being shared. If one of these segments is being shared, 
each task sharing the segment accesses the same copy of the 
segment. When a segment number is assignee by the Memory 
Manager, the lowest available segment (or segments for 
objects of size greater than 128K bytes) beginning with 
segment 80 will be used. 

6. Only one copy of the group work space segment (segment 46 in 
this example) exists per task group. All tasks in the task 
group have unlimited access to this segment. Only one copy 
of the segment that contains group system space (segment 44 
in this example) exists per task group. All tasks in the 
task group have read and execute access to this segment. 
Both the group work space and the group system space 
segments are dynamically expanded as demancs are made on 
them. Each space can grow to a maximum of 256K bytes if the 
adjacent ascending segment descriptor has not been 
previously allocated to contain a task private segment. 
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Figure 4-7. Taste- Address Space in EMMU System 
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